Info-Mac 4/Info_Mac IV CD-ROM (Pacific HiTech Inc.)(August 1994).iso/Periodicals/CSMP/C.S.M.P. Digest, Issue 3.021

Internet Message Format | 1994-06-09 | 69KB

From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-021
Date: Fri, 29 Apr 94 18:37:31 MET DST

C.S.M.P. Digest             Fri, 29 Apr 94       Volume 3 : Issue 21

Today's Topics:

        CW longjmp & destructor
        Complete File Directory
        Extensions-Patches w-PowerPC
        Help: SetEventMask, MacApp, Sub-launching
        Macintosh Disk Cache fix -- 25 times speedup
        PowerMac Programming & the data bus
        QuickDraw GX Questions
        Quitting faceless background applications



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.


-------------------------------------------------------

>From [e-mail] (SHOJI UEDA)
Subject: CW longjmp & destructor
Date: Fri, 8 Apr 1994 12:57:45 GMT
Organization: B.U.G. Inc.

Hi, CodeWarrior users and Metrowerks guys

I found a "longjmp & destructor" problem with CW 1.0a4 PPC/68K.
Here is my test code.
--
#include <Types.h>
#include <setjmp.h>

class CTest {
public:
        long field;
        CTest(void);
        ~CTest(void);
};

CTest::CTest(void)
{
        field = 'CNST';
}

CTest::~CTest(void)
{
        field = 'DEST';
}

class CTest2 {
public:
        long field;
        CTest2(void);
        ~CTest2(void);
};

CTest2::CTest2(void)
{
        field = 'CNST';
}

CTest2::~CTest2(void)
{
        field = 'DEST';
}

jmp_buf env;

void Func(void)
{
        CTest ctest;

        ctest.field = 'FUNC';
        longjmp(env, 1);
}

void main(void)
{
        CTest2 ctest2;

        ctest2.field = 'MAIN';
        DebugStr("\pSTARTED");
        if (setjmp(env) == 0) {
                Func();
                DebugStr("\pSUCCEEDED");
        }
        else
                DebugStr("\pFAILED");
        DebugStr("\pEND");
}
- -
This code will cause crash. This is because ctest defined in Func() already
was removed from stack frame but its destructor called.

I tested this code with MPW CFront. CFront never call removed obejct's
destructor. I don't understand removed object's destructor should be called
or not. But MacApp3.1 failure mechanism uses longjmp() and destructor.

Thanks,


+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Tue, 12 Apr 1994 20:11:04 GMT
Organization: Apple Computer

SHOJI UEDA, [e-mail] writes:
> This code will cause crash. This is because ctest defined in Func() already
> was removed from stack frame but its destructor called.

Something's wrong here. longjmp() does NOT call destructors of local
variables. I've been using setjmp/longjmp in an exception library of my own
with no problems, and PowerPlant also uses them.

Take a look at the disassembly of your code and see what's happening around
the call to longjmp...

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Dan Podwall)
Date: Wed, 13 Apr 1994 16:36:43 GMT
Organization: Metrowerks, Inc.

SHOJI UEDA ([e-mail]) wrote:
: Hi, CodeWarrior users and Metrowerks guys

: I found a "longjmp & destructor" problem with CW 1.0a4 PPC/68K.
: Here is my test code.

As you know, longjmp doesn't call destructors for objects in
the stack frames that it pops. But there is a bug in the C++ runtime
that causes it to get confused and try to destroy objects that
were in frames that were popped by a longjmp. This will be fixed in
DR3. I'm not sure if this is something that we can make an interim fix
for or not.

Dan Podwall
Metrowerks, Inc.


+++++++++++++++++++++++++++

>From [e-mail] (John McEnerney)
Date: Thu, 14 Apr 1994 02:17:55 GMT
Organization: The World Public Access UNIX, Brookline, MA

Jens Alfke <[e-mail]> writes:

>SHOJI UEDA, [e-mail] writes:
>> This code will cause crash. This is because ctest defined in Func() already
>> was removed from stack frame but its destructor called.

>Something's wrong here. longjmp() does NOT call destructors of local
>variables. I've been using setjmp/longjmp in an exception library of my own
>with no problems, and PowerPlant also uses them.

This is actually a bug in CodeWarrior. The way the destruction of local
objects is implemented it is possible for the destructors to be called if
you exit the routine froma longjmp(). It will be fixed in DR3.

-- John McEnerney, Metrowerks PowerPC Product Architect


---------------------------

>From [e-mail] (Matt Gallagher)
Subject: Complete File Directory
Date: 8 Apr 1994 03:52:46 GMT
Organization: Australian National University

I need to get a complete directory listing of an HFS volume in Think C
5.0.4.
I've tried recursively calling PBGetCatInfo, but this is ridiculously slow
on my 500mb hard drive. Does anyone have any tips on how to do this more
quickly?

Thanks in advance,
Matt Gallagher
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Scott Gruby)
Date: 8 Apr 1994 04:19:53 GMT
Organization: Harvey Mudd College, Claremont CA

In article <cowcorp-080494135647@150.203.60.160>, [e-mail]
(Matt Gallagher) wrote:

> I need to get a complete directory listing of an HFS volume in Think C
> 5.0.4.
> I've tried recursively calling PBGetCatInfo, but this is ridiculously slow
> on my 500mb hard drive. Does anyone have any tips on how to do this more
> quickly?
>
> Thanks in advance,
> Matt Gallagher
> [e-mail]

Sorry I can't answer this question, but on a similar note, what is the
easiest way to list all files in a directory...as fast as possible would be
great, but not necessary?

Thanks.

--
Scott Allen Gruby                         ([e-mail])
Macintosh Student System Manager
Academic Computing, Harvey Mudd College
Claremont, CA
         Finger [e-mail] for public key

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 9 Apr 1994 13:17:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <cowcorp-080494135647@150.203.60.160>, [e-mail]
(Matt Gallagher) writes:

> I need to get a complete directory listing of an HFS volume in Think C
> 5.0.4.

There are only a couple of methods you can use.

If you want the directory struture (you want to know what files and
subdirectories are in a directory), you'll have to use PBGetCatInfo (as you
said you've already tried).  I haven't tried this to find out if it makes any
difference but... the Macintosh file system keeps a catalog hint when
PBGetCatInfo is used with a positive index. That means that if you index
through a directory using 1, 2, 3, 4..., the file system can find the next
sequential directory entry a little faster.  So, you might get a little better
performance if you index through a complete directory level before dropping
down a level to index through its subdirectories.  I don't know because I
haven't tried it. (This would be harder to code, though.)

If you don't need the directory structure and only need a list of all of the
objects (files and directories) on the volume, you can use PBCatSearch to get
fill an array of FSSpecs.  This will be a lot faster on local HFS hard disks
but will probably be slower than the recursive search if the volume is an
AppleShare volume.  (I tested this when writing the Technical Note "Searching
Volumes-Solutions and Problems" and found that the search time for finding all
files and directories on a Developer CD  was around 18 seconds with
PBCatSearch. It took 6 minutes and 36 seconds with a recursive indexed search.)

- Jim Luther


+++++++++++++++++++++++++++

>From [e-mail] (Brian Bechtel)
Date: 14 Apr 1994 21:36:28 -0700
Organization: Apple Computer, Inc., Cupertino, California

[e-mail] (Scott Gruby) writes:

>In article <cowcorp-080494135647@150.203.60.160>, [e-mail]
>(Matt Gallagher) wrote:

>> I need to get a complete directory listing of an HFS volume in Think C
>> 5.0.4.
>> I've tried recursively calling PBGetCatInfo, but this is ridiculously slow
>> on my 500mb hard drive. Does anyone have any tips on how to do this more
>> quickly?

>Sorry I can't answer this question, but on a similar note, what is the
>easiest way to list all files in a directory...as fast as possible would be
>great, but not necessary?

MoreFiles.  MoreFiles.  MoreFiles.

MoreFiles is an excellent collection of file manager sample code by Jim
Luther of DTS.  It's available from

  ftp://ftp.apple.com/dts/mac/sc/morefiles.1.1.1.hqx

It has complete, working code which does both of the requested items
above.

--Brian Bechtel     [e-mail]     "My opinion, not Apple's"

---------------------------

>From [e-mail] (Greg Landweber)
Subject: Extensions-Patches w-PowerPC
Date: 09 Apr 1994 16:26:51 GMT
Organization: (none)

If I load and prepare a PowerPC code fragment from an INIT (using
GetDiskFragment or loading it from a resource and calling
GetMemFragment), will it be unloaded when my INIT exits?  I want the
fragment to persist until the Mac is shut down, as if I had loaded and
detached a 680x0 code resource in the system heap.

Basically, I have a code fragment containing a number of trap patches.
The entry point is the routine that installs the trap patches and a
Gestalt Selector routine also within the code fragment.

Thanks for your help.

-- Greg "Buttons" Landweber
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Alan Lillich)
Date: Mon, 11 Apr 1994 23:38:37 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Greg
Landweber) wrote:
>
> If I load and prepare a PowerPC code fragment from an INIT (using
> GetDiskFragment or loading it from a resource and calling
> GetMemFragment), will it be unloaded when my INIT exits?  I want the
> fragment to persist until the Mac is shut down, as if I had loaded and
> detached a 680x0 code resource in the system heap.
>
> Basically, I have a code fragment containing a number of trap patches.
> The entry point is the routine that installs the trap patches and a
> Gestalt Selector routine also within the code fragment.
>
> Thanks for your help.
>
> -- Greg "Buttons" Landweber
>    [e-mail]

What you suggest works just fine.  I would suggest using the fragment's
init routine to install the patches, then your init just has to call
GetDiskFragment and make sure there is no error.  Note:  If VM is on
GetDiskFragment will use file mapping on the data fork.  This may or may
not be desirable, i.e. is your code only used at times when page faults are
safe?

Alan Lillich.

+++++++++++++++++++++++++++

>From [e-mail] (Bill Hofmann)
Date: Tue, 12 Apr 1994 01:55:49 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

[e-mail] (Greg Landweber) writes:
>If I load and prepare a PowerPC code fragment from an INIT (using
>GetDiskFragment or loading it from a resource and calling
>GetMemFragment), will it be unloaded when my INIT exits?  I want the
>fragment to persist until the Mac is shut down, as if I had loaded and
>detached a 680x0 code resource in the system heap.
Once a fragment is loaded (at INIT time), it's open forever.  Of course,
if you load a fragment from a resource, you had best DetachResource...

>Basically, I have a code fragment containing a number of trap patches.
>The entry point is the routine that installs the trap patches and a
>Gestalt Selector routine also within the code fragment.
Yup, that'll work.  If you want to install fat patches, **as you should**
most of the time, your entry point should instead be a routine which
returns addresses of patches and takes old trap addresses, since you'll
need to build a fat routine descriptor for each patch, and to do that,
you need to also have a 680x0 version.  It's kind of an ugly mess, which
can be archtected nicely with some effort.

If your patch is big enough that a mixed mode switch is worthwhile (> a
few hundred anyway, probably a few thousand) lines of compiled code, then
you can just patch native, and try this: make your initialization routine
do the initing and patching, and you don't have to do anything but load
the fragment: the init routine gets called automatically!  It's quite
easy to do.

>Thanks for your help.
>-- Greg "Buttons" Landweber
>   [e-mail]
No problem.
--
-Bill Hofmann                    [e-mail]
 Fresh Software and Instructional Design    [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Leonard Rosenthol)
Date: Tue, 12 Apr 1994 18:36:58 GMT
Organization: Aladdin Systems, Inc.

In article <[e-mail]>, [e-mail] (Bill Hofmann) wrote:

> [e-mail] (Greg Landweber) writes:
> >If I load and prepare a PowerPC code fragment from an INIT (using
> >GetDiskFragment or loading it from a resource and calling
> >GetMemFragment), will it be unloaded when my INIT exits?  I want the
> >fragment to persist until the Mac is shut down, as if I had loaded and
> >detached a 680x0 code resource in the system heap.
>
> Once a fragment is loaded (at INIT time), it's open forever.  Of course,
> if you load a fragment from a resource, you had best DetachResource...
>
   True, it is open forever (well, assuming the file doesn't get closed ;)
- HOWEVER the connection ID that you get back from
GetMemFragment/GetDiskFragment is _PROCESS_ relative so that in order to
use the fragment in multiple processes/application you have to either
reload the fragment each time OR precompute and store the entry points at
startup.


Leonard
- ------------------------------------------------------------------------
Leonard Rosenthol                      Internet:       [e-mail]
Director of Advanced Technology        AppleLink:      MACgician
Aladdin Systems, Inc.                  GEnie:          MACgician

+++++++++++++++++++++++++++

>From [e-mail] (joe zobkiw)
Date: Wed, 13 Apr 1994 12:26:38 GMT
Organization: Datawatch Corporation

In article <[e-mail]>,
[e-mail] (Leonard Rosenthol) wrote:

> In article <[e-mail]>, [e-mail] (Bill Hofmann) wrote:
>
> > [e-mail] (Greg Landweber) writes:
> > >If I load and prepare a PowerPC code fragment from an INIT (using
> > >GetDiskFragment or loading it from a resource and calling
> > >GetMemFragment), will it be unloaded when my INIT exits?  I want the
> > >fragment to persist until the Mac is shut down, as if I had loaded and
> > >detached a 680x0 code resource in the system heap.
> >
> > Once a fragment is loaded (at INIT time), it's open forever.  Of course,
> > if you load a fragment from a resource, you had best DetachResource...
> >
>    True, it is open forever (well, assuming the file doesn't get closed ;)
> - HOWEVER the connection ID that you get back from
> GetMemFragment/GetDiskFragment is _PROCESS_ relative so that in order to
> use the fragment in multiple processes/application you have to either
> reload the fragment each time OR precompute and store the entry points at
> startup.
>

>> reload the fragment each time OR precompute and store the entry points

This sounds a bit confusing but...I load numerous fragments at startup (via
an INIT), and call them all throughout the time the machine is on. Simply
GetResource, DetachResource, GetMemFragment, and go...it works fine.

___________________________________________________________
_/_/_/_/   Joe Zobkiw                                   ,,,
    _/     Senior Software Engineer                     - -
  _/       Datawatch Corporation                         L
_/_/_/_/   [e-mail]                          -

+++++++++++++++++++++++++++

>From [e-mail] (Bill Hofmann)
Date: Thu, 14 Apr 1994 00:35:40 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

[e-mail] (joe zobkiw) writes:
...
>>> reload the fragment each time OR precompute and store the entry points

>This sounds a bit confusing but...I load numerous fragments at startup (via
>an INIT), and call them all throughout the time the machine is on. Simply
>GetResource, DetachResource, GetMemFragment, and go...it works fine.

Yes, Leonard, Joe's right.  I've done it too.  You don't have to worry
about the process-relative nature because, of course, you're in the system
context at INIT time.  But your general comment is well-taken.

--
-Bill Hofmann                    [e-mail]
 Fresh Software and Instructional Design    [phone]

+++++++++++++++++++++++++++

>From [e-mail] (joe zobkiw)
Date: Thu, 14 Apr 1994 12:21:47 GMT
Organization: Datawatch Corporation

In article <[e-mail]>, [e-mail] (Bill Hofmann) wrote:

> [e-mail] (joe zobkiw) writes:
> ...
> >>> reload the fragment each time OR precompute and store the entry points
>
> >This sounds a bit confusing but...I load numerous fragments at startup (via
> >an INIT), and call them all throughout the time the machine is on. Simply
> >GetResource, DetachResource, GetMemFragment, and go...it works fine.
>
> Yes, Leonard, Joe's right.  I've done it too.  You don't have to worry
> about the process-relative nature because, of course, you're in the system
> context at INIT time.  But your general comment is well-taken.
>

Leonard responded to me:

"That's because your code has a SINGLE entry point and you built it with
a MixedMode Header on the resource.  If you DON'T do that, and you resolve
(FindSymbol) at runtime, the connection ID's are not valid across
processes."

Now, he is right, I have a single entry point. Maybe there is more to it
with multiple entry points. I don't know since I've not had to deal with
that yet.

___________________________________________________________
_/_/_/_/   Joe Zobkiw                                   ,,,
    _/     Senior Software Engineer                     - -
  _/       Datawatch Corporation                         L
_/_/_/_/   [e-mail]                          -

+++++++++++++++++++++++++++

>From [e-mail] (Leonard Rosenthol)
Date: Thu, 14 Apr 1994 19:01:42 GMT
Organization: Aladdin Systems, Inc.

In article <[e-mail]>, [e-mail] (Bill Hofmann) wrote:

> [e-mail] (joe zobkiw) writes:
> ...
> >>> reload the fragment each time OR precompute and store the entry points
>
> >This sounds a bit confusing but...I load numerous fragments at startup (via
> >an INIT), and call them all throughout the time the machine is on. Simply
> >GetResource, DetachResource, GetMemFragment, and go...it works fine.
>
> Yes, Leonard, Joe's right.  I've done it too.  You don't have to worry
> about the process-relative nature because, of course, you're in the system
> context at INIT time.  But your general comment is well-taken.
>
   Depends on whether you build a mixed mode header on the resource itself
and whether you have one or multiple entry points.

   If the former situation (single entry point, with no callbacks, and
built with an MM header), then you are correct - you can load and call and
be just fine.   BUT if you have a code frag with multiple entry points and
you need to call FindSymbol, then the results are only relative to the
process  - you need the correct connectionID for the process or FindSymbol
will fail :(

Leonard
- ------------------------------------------------------------------------
Leonard Rosenthol                      Internet:       [e-mail]
Director of Advanced Technology        AppleLink:      MACgician
Aladdin Systems, Inc.                  GEnie:          MACgician

---------------------------

>From [e-mail] (Steve Herman)
Subject: Help: SetEventMask, MacApp, Sub-launching
Date: Wed, 13 Apr 1994 12:48:37 -0500
Organization: BCSS

MacApp 3.0.1(bullet) calls SetEventMask in it's DoRealInitToolBox()
function to set SysEvtMask to everyEvent (0xFFFF).  According to Inside Mac
the normal value of SysEvtMask is 0xFFEF which masks out keyUp events.

Where I have seen a problem is when I sub-launch applications from a MacApp
application.  It appears that sub-launched applications "inherit" the value
of SysEvtMask from the application which launched them.  Can anyone confirm
that this is true???

Does anyone know just how/when a *sub-launched* application's low memory
globals get initialized?  In my MacApp program I tried setting SysEvtMask
to 0xFFEF, calling LaunchApplication() and then putting it back to 0xFFFF
(to keep MacApp happy). But the sub-launched application still showed
0xFFFF after it launched.  Do I perhaps need to leave my SysEvtMask set at
0xFFEF until WaitNextEvent has been called a few times and the sub-launch
has *really* taken place????

If I set SysEvtMask back to 0xFFEF in my MacApp application (and leave it
that way) am I asking for trouble (I briefly searched through the source
and didn't see anything obvious which MacApp was doing with keyUps)?

Despite all the documentation I've been able to find which states that apps
which modify SysEvtMask should save it's previous value and then restore it
before quitting, I can't find any indication that MacApp does this. As far
as I can tell, however, this doesn't seem to cause a problem.

The reason I brought all this up is that we use an apparently "brain-dead"
off the shelf product which I need to sub-launch AND which seems to get
confused when it has to deal with keyUp events.

Thanks for any insight...

Steve

- --------------------------------------------------
- Steve Herman - BCSS
- Boeing Computer Support Services
- Huntsville, AL
- --------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Thu, 14 Apr 1994 07:10:56 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Steve Herman ([e-mail]) wrote:
> MacApp 3.0.1(bullet) calls SetEventMask in it's DoRealInitToolBox()
> function to set SysEvtMask to everyEvent (0xFFFF).  According to Inside Mac
> the normal value of SysEvtMask is 0xFFEF which masks out keyUp events.

> Where I have seen a problem is when I sub-launch applications from a MacApp
> application.  It appears that sub-launched applications "inherit" the value
> of SysEvtMask from the application which launched them.  Can anyone confirm
> that this is true???

Yes, I've dealt with this before and it is true.  You've nailed it.  I
suspect your fix will work too, but I'll bet you've tried and know if it
will work by now.  I solved it by making the sublaunched application fix
its event mask, which isn't an option for you apparently.

> If I set SysEvtMask back to 0xFFEF in my MacApp application (and leave it
> that way) am I asking for trouble (I briefly searched through the source
> and didn't see anything obvious which MacApp was doing with keyUps)?

You simply won't get keyUp method calls, but since you probably don't use
them, it won't matter if you turn them off.

Jon


---------------------------

>From Stuart Cheshire <[e-mail]>
Subject: Macintosh Disk Cache fix -- 25 times speedup
Date: 9 Apr 1994 17:25:44 GMT
Organization: Stanford University

Here's a message I posted on Thursday to the Nuntius mailing list:

- ----------------------------------------------------------------

Has anyone else noticed that at the end of extracting a binary in
Nuntius the disk light comes on, stays on for a few seconds, and
freezes the Mac for that duration? It gets unbearable if you have
a large disk cache, but even with only a 256K cache it can freeze
the Mac for up to 5 seconds.

This is not the fault of Nuntius -- many other programs like BinHex
decoders, uudecoders, archive expanders etc. seem to suffer the same
problem.

This really annoys me. One of the good features of Nuntius is the way
it lets you continue working while it is doing other things in the
background, so having it freeze like this is particularly galling.

The problem is that Nuntius (and other programs) write their data to
disk in chunks (say 4K each) and the Mac caches the blocks in its
disk cache. When the file is closed the data is finally written to disk,
and this is what causes the big freeze up. It would be much better if
the data were written continually to disk, instead of in one big burst
at the end.

Yesterday morning I wrote a little INIT which sets the File Manager
"don't cache" bit for disk writes of 1K or more. It does this by
installing the following patch on the _Write system call:

                 tst.w   IOParam.ioRefNum(a0)         ; Is this a file write?
                 bmi.s   @sys_write
                 cmp.l   #1024, IOParam.ioReqCount(a0); Is it at leask 1K?
                 blo.s   @sys_write
                 ori.w   #0x20, IOParam.ioPosMode(a0) ; Set "Don't cache" bit
extern sys_write:jmp     0x12345678                   ; Resume the system call

One surprising artifact of this is that it not only amortises the disk
time over all the writes, but it also makes it 25 times faster.

What?

Yes, it's true.

I set my disk cache to 768K, and wrote a test program which wrote to a
file in 32 blocks of 16K each, making a total of 512K.

Without the INIT, the writes took almost no time, but the Close call
took 11 seconds, averaging about 45K/second write rate.

With the INIT, the whole thing took under half a second, averaging
over a megabyte per second.

Go figure.

This may not make much difference to people connecting over modem, but
for people on Ethernet it makes a huge difference.

The INIT is below, in BinHex form. Decode it, install it, and let me
know what you think.

It has no ICON, because the total size of the INIT (including balloon
help) is just under 1K, and it seemed a pity to spoil that with a big
fat colour icon. (Besides, I couldn't be bothered to draw one.)

- ----------------------------------------------------------------

Here is one reply I got, which proves I wasn't hallucinating:

>> From: [e-mail] (Joanna L. Castillo)
>> Subject: Re: Long Mac freezes with Nuntius (and other program)
>>
>> Hi, Stuart -
>>
>> >Yesterday morning I wrote a little INIT  [ ... ]
>>
>> Wow!  I installed the INIT... I tried copying a folder that had several
>> files and sub-folders (a little over 900K total) to a floppy.  With the
>> INIT installed, it took about 30 seconds.  Without, it took 2 minutes.
>> Thank you so much.
>>
>> Joanna.
>>
>> FYI:  I'm running a Mac IIci, 24MB RAM, cache card, ethernet, tuned
>>       7.0.1 system, several inits, and disk cache set at 512K.

I'll post the source code for the INIT, and the test program, to a
separate thread. This INIT itself is below.

Stuart Cheshire <[e-mail]>
 * <A HREF="file://brubeck.stanford.edu/www/cheshire-bio.html">WWW</A>
 * Stanford Distributed Systems Group Research Assistant
 * Escondido Village Resident Computer Coordinator
 * Macintosh Programmer

(This file must be converted with BinHex 4.0)

:$&GbDA4P9'KbEh9RD!"*6NP89h*8D!!!!!!!!!!!!rJBk3!!!!!"!!!!!i8!!!+
&!!!!F`!)6Ud!3Le!!!`-J!#!!!"M"(!!B%)-VJ!!1TJ!$'3S$&GbDA4P9'KbEh9
RD&S#!!!!58j*9&Gb9'J"!2rrrrm!!%P1594AFP4S!3$rrrrr!!!!!!!!!!!!!!!
!!!!!!!!!UFK3'J!!!!!!!!2i!)!!!'-'F!"J!!$L)!aQ$#m(6VVr(PL2B!!!dNU
(CJi[$%kk!0"BMh!!B!!!`!J(!!"R!P+()%a`!$!J4N"Q!U!K9B!X!,b(Ba3U"`b
'!!!kQ'8Q$)F!!$UBCA"JBVb(C"3U"Jb'!!!kQ'48$)F!!$UBC&KJ'#!-B()J6$)
J)!D3!)F!!!%H,``[#+Q53IVrq#K)B3!!a#KI6R9+D!!BDa!-U!!!"!!!*'8'!'J
!)!!X6[N50&Ci6R919[rm51F(!#`Z!!JZ"J+(!!!)!%U(C`4`!@!#F!!D!%U(Cd!
Z2!!!"!"#Tbmm!3#SENkk!*`YArrm3UF[2!%!UQj1ZJ#-)#lrr,#ICJBZ2!!!!J!
#KJ!!"rqqKQ)',$`!!+LI3UFr"Km&6VS!C#eIrra#Tbmm!3#SRdkk!&3J,[rmX*p
@`%3!60m!i%jH6R@09(*KF%&fB@PXB@*XC3!!,`Y(q[p@-$bJ!k0'*SK"q[mb-$b
J!k*(,c`!!+'B6VVr3%S!@)pR"%kk!"SQAdje)Pm5(c!I5J&R"+G'B!+M4Lk)6Y%
LAh!"SCK1d3!!!2B!!J!!!!!!!!!!!!%!kJ!"j&4SC5"AFQPdC94SFQpeCfJJ4AK
dC@jcD@pZ)'*jF'&cFf9c)(4SC5"6HA0dC@h9Fb"MEh"j,@*KBfXJC'PcDb"MB@0
SC5"QEh)JB@aX)(GbDA4PFb"dEb"NDA0V)'pQ)$&,)'pb)'GbC@&dCA)Z)%pZ)'e
j)&&eB@4bB5!h-$!X)(GTG'JJB5"NDA0V)'0KBfKP)'pQ)$-i0%XX)(4SDA-JE@&
VCA-JBf9bG'&TEL"KF("XD@0KG'P[ER-J-M8JG'PYCA-JCQ&cG'9b)(GSC@iJG'K
PH5"hFQPdC5"dEb"NDA0V,J!!!!!E!3#!!!!!!c%Z-""AFQPdC94SFQpeCfJJ-5i
`!!!!4J%!J!!!!!-a,M!lU5!fG'JJ3A"bD@`J-6Nj0#"6G(9KFR3J3fKPFfKTFQ8
J2'0SCA0SDA*P3'0c,R0dB@jQEh*N,Q9NG6i!!!%!!!!$K3!!!S8!!!"c!*@8'!Y
N!!!!(!"Q!!**6NP8!!!!'QKQC()!!!!QGQ9bF`!"!$)!!!!!8!!!!!!!!!$T`2r
r!!!")J!!!!!!![rr!!!#(!#9NM3!!Irr!!!#1`#9Nf`-9h*TG'98D(*[G@GS-U)
:

+++++++++++++++++++++++++++

>From [e-mail] (ROGER BAUCHSPIES)
Date: 9 Apr 1994 21:26:54 GMT
Organization: University of Nebraska--Lincoln

Stuart Cheshire ([e-mail]) wrote:
: Here's a message I posted on Thursday to the Nuntius mailing list:

: ------------------------------------------------------------------

: Has anyone else noticed that at the end of extracting a binary in
: Nuntius the disk light comes on, stays on for a few seconds, and
: freezes the Mac for that duration? It gets unbearable if you have
: a large disk cache, but even with only a 256K cache it can freeze
: the Mac for up to 5 seconds.

This is due to the design of the cache, which always writes cached
blocks in 512 byte pieces, regardless of how large they were when they
cache grabbed them. I am writing a highly intelligent disk cache and
will be releasing it later this year. Depending on the marketplace at
that time, I may release both the source code and object code as
public domain.

Steve Kiene
MindVision Software


+++++++++++++++++++++++++++

>From Cameron Esfahani <[e-mail]>
Date: Sun, 10 Apr 1994 05:27:14 GMT
Organization: Apple Computer, Inc.

In article <2o6oeo$[e-mail]> Stuart Cheshire,
[e-mail] writes:
> Has anyone else noticed that at the end of extracting a binary in
> Nuntius the disk light comes on, stays on for a few seconds, and
> freezes the Mac for that duration? It gets unbearable if you have
> a large disk cache, but even with only a 256K cache it can freeze
> the Mac for up to 5 seconds.

There is a perfectly logical explanation of why the disk cache
sucks so bad in cases like this.  If the disk cache gets flushed,
and there are a large number of dirty blocks in there, each block
gets written out 1 at a time.  This means if you have a 1Meg cache
and it has 256K dirty, then you will write out 512 blocks to
disk.  Even if you have a fast drive this takes a little time.

This gives me a chance to evangelize the use of the 'noCacheBit'
which is defined in SysEqu.a.  This tells the file system to not
cache this transaction.  Please use this bit if you know you are
not going to use the information that you are reading or writing
again.  If you don't, the file system has to try to read your
mind, and we all know how successfully that works.

Another way to speed up your usage of the file system is to never,
ever use the newline mode in reading from a file.  The file system
has to read data from the file 1 byte at a time.  This is slow.
If you want to simulate this, read from the file in large (>4K)
chunks and search through it yourself.

This leads me into my next tip: read and write in large chunks.
It really is much more efficient to read and write in >4K chunks
and pull your data out of there yourself.

With these few tips, you can increase your enjoyment of the Mac
file system.

Cameron Esfahani
[e-mail]
General File-System Dude

+++++++++++++++++++++++++++

>From [e-mail] (Jon W‰tte)
Date: 10 Apr 1994 11:11:08 GMT
Organization: The Royal Institute of Technology

In <2o6oeo$[e-mail]> Stuart Cheshire <[e-mail]> writes:

>Yesterday morning I wrote a little INIT which sets the File Manager
>"don't cache" bit for disk writes of 1K or more. It does this by
>installing the following patch on the _Write system call:

This has long been needed.

>Without the INIT, the writes took almost no time, but the Close call
>took 11 seconds, averaging about 45K/second write rate.
>With the INIT, the whole thing took under half a second, averaging
>over a megabyte per second.
>Go figure.

That's because the disk cache flushes itself in 512 byte blocks.
Yes, that's right, at this day and age, the disk cache still
iterates over its 512 byte blocks, writing ONE AT A TIME.

However, the next major system software release will have
FINALLY fixed this problem. Yay! So your INIT should maybe
check to see that the system version is < 7.2 or something?

Cheers,

                    / h+

--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --
    Not speaking for IBM.

+++++++++++++++++++++++++++

>From Stuart Cheshire <[e-mail]>
Date: 10 Apr 1994 19:14:06 GMT
Organization: Stanford University

In article <2o8msc$[e-mail]> Jon W!tte, [e-mail]
writes:
>However, the next major system software release will have
>FINALLY fixed this problem. Yay! So your INIT should maybe
>check to see that the system version is < 7.2 or something?

Hey, the INIT is <1K. This is not a major software development. This is
simply the result of waking up at 6:00am due to getting drunk the night
before. Don't install it if it's not appropriate for your system.

Stuart Cheshire <[e-mail]>
 * <A HREF="file://brubeck.stanford.edu/www/cheshire-bio.html">WWW</A>
 * Stanford Distributed Systems Group Research Assistant
 * Escondido Village Resident Computer Coordinator
 * Macintosh Programmer

+++++++++++++++++++++++++++

>From [e-mail] (Philip Machanick)
Date: Mon, 11 Apr 1994 14:13:39 +0200
Organization: Computer Science Dept, U of Witwatersrand

In article <2o9j5u$[e-mail]>, Stuart Cheshire
<[e-mail]> wrote:

> Hey, the INIT is <1K. This is not a major software development. This is
> simply the result of waking up at 6:00am due to getting drunk the night
> before. Don't install it if it's not appropriate for your system.

Clearly still having fun. I may be at Stanford somewhere around 18 April.
Maybe I'll see you then.
--
Philip Machanick                   [e-mail]
Department of Computer Science, University of the Witwatersrand
2050 Wits, South Africa
phone [phone]  fax [phone]
>From [e-mail] (eric larson)
Subject: Macintosh Disk Cache fix -- 25 times speedup
Date: 11 Apr 94 18:12:03 -0500
Organization: FidoNet:* File Edit View Label Special                 ? D (1:2605/620)

 > This leads me into my next tip: read and write in large chunks.
 > It really is much more efficient to read and write in >4K chunks
 > and pull your data out of there yourself.

 > With these few tips, you can increase your enjoyment of the Mac
 > file system.

How about a quick & -dare I say- dirty code snip?

+++++++++++++++++++++++++++

>From [e-mail] (Ron Hunsinger)
Date: Wed, 13 Apr 94 00:09:16 PST
Organization: Berkeley Macintosh Users Group

Stuart Cheshire <[e-mail]> writes:

>Yesterday morning I wrote a little INIT which sets the File Manager
>"don't cache" bit for disk writes of 1K or more. It does this by
>installing the following patch on the _Write system call:

Question: what happens in the following circumstance?

   1)  A program reads some data in several chunks of 512 bytes each
       (or even reads it all in one big chunk), having as a side effect
       that a copy of the data is now present in the cache.

   2)  The program modifies the data, and writes it out in one large
       chunk.  Because of your patch, the cache is bypassed.

   3)  The program re-reads the data.

Does the program get the stale data that was placed in the cache in
step 1, or the updated data that was written in step 2?

-Ron Hunsinger

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 14 Apr 1994 16:40:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail] (Ron Hunsinger)
writes:

> Question: what happens in the following circumstance?
>
>    1)  A program reads some data in several chunks of 512 bytes each
>        (or even reads it all in one big chunk), having as a side effect
>        that a copy of the data is now present in the cache.
>
>    2)  The program modifies the data, and writes it out in one large
>        chunk.  Because of your patch, the cache is bypassed.
>
>    3)  The program re-reads the data.
>
> Does the program get the stale data that was placed in the cache in
> step 1, or the updated data that was written in step 2?

You don't need to worry about this because the Macintosh file system cache code
takes care of making sure you get the correct data. Any writes that bypass the
cache will remove those blocks from the cache so the read in your step 3 would
come from the disk driver, not the cache.

So, the only way you can get data that's inconsistant with the file system
cache is to bypass the file system and read directly from the disk driver.
That's the reason we (Apple) tell developers of disk repair utilities to
unmount a volume before they read the disk directly. Unmounting a volume
flushes all dirty blocks (blocks that have been changes in the cache, but not
on disk) to disk and then trashes all cache blocks associated with that volume.

- Jim Luther


+++++++++++++++++++++++++++

>From [e-mail] (ROGER BAUCHSPIES)
Date: 15 Apr 1994 06:34:42 GMT
Organization: University of Nebraska--Lincoln

Jump Long ([e-mail]) wrote:
: So, the only way you can get data that's inconsistant with the file system
: cache is to bypass the file system and read directly from the disk driver.
: That's the reason we (Apple) tell developers of disk repair utilities to
: unmount a volume before they read the disk directly. Unmounting a volume
: flushes all dirty blocks (blocks that have been changes in the cache, but not
: on disk) to disk and then trashes all cache blocks associated with that volume.

Apple should tell developers to do the same for SCSI drivers with
caches. RapidTrak and Iomega SCSI drivers contain their own cache,
which they do NOT flush when a volume is unmounted. This causes
problems with programs that bypass the SCSI driver and talk directly
to the disk. As a rule, any cache should stop caching a volume if it
is not online.

Steve Kiene
MindVision Software

---------------------------

>From [e-mail] (Phillip Burgess)
Subject: PowerMac Programming & the data bus
Date: Thu, 14 Apr 1994 06:37:27 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

A couple of questions about programming on the Power Macintosh...

How can I best take advantage of the PowerMac's 64-bit path to memory when
working with 32-bit integer values?  If I'm writing a number of 32-bit
values to a contiguous chunk of memory, do they (or can they) get stored
in pairs about as quickly as storing half as many noncontiguous values?
If so, what sort of flaming hoops, if any, do I need to jump through?
If memory can be accessed in this fashion, what about writing 4 contiguous
16-bit values, or 8 contiguous bytes?  Same effect?

Also, how many integer and FP registers am I likely to actually have at my
disposal when using a C compiler such as MetroWorks'?
--
  Phillip Burgess   ([e-mail])

+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Thu, 14 Apr 1994 08:53:31 GMT
Organization: Adobe Systems Incorporated

Phillip Burgess writes
> A couple of questions about programming on the Power Macintosh...
>
> How can I best take advantage of the PowerMac's 64-bit path to memory when
> working with 32-bit integer values?  If I'm writing a number of 32-bit
> values to a contiguous chunk of memory, do they (or can they) get stored
> in pairs about as quickly as storing half as many noncontiguous values?
> If so, what sort of flaming hoops, if any, do I need to jump through?
> If memory can be accessed in this fashion, what about writing 4 contiguous
> 16-bit values, or 8 contiguous bytes?  Same effect?

On the 601 (which I assume is what we're talking about here), the the cache
sits between the processor and the 64 bit databus. The path between the
fixed-point unit and the cache is only 32 bits wide. There is a 64 bit
datapath between the floating-point unit and the cache. The cache
stores/fetches entire 32 byte blocks to/from memory (or secondary cache) at
a time. Hence each 32 bit write from the fixed-point unit does not result in
a memory transaction if you are writing to contiguous addresses. Unless you
are writing to uncached memory. In that case the only way to get 64 bit bus
transactions on at least some (if not all) current hardware is to use
floating-point loads and stores. That may be a win even if you have to add a
couple of cached loads and stores to make it work (e.g. to handle misaligned
cases).

For writing contiguous regions of cached memory, you'll want to look into
the dcbz instruction. Normally when you write to an address that is not in
the cache, the hardware fetches that block before handling the store. This
is obviously necessary as the cache will want to store the entire 32 byte
block later and if you only wrote 32 bits of that, the rest of the block has
to be valid. The dcbz (data cache block zero) instruction says "I'm going to
write the entire cache block around this address so just make me a cache
block of zeros for that address." This has the effect of storing zero to all
addresses covered by the cache block.

There are a couple difficulties with dcbz. The first is discovering the
cache block size. This is important as the correctness of your code will
depend upon this size. A second difficulty is writing code that can do the
dcbz instruction for each cache block for different block sizes. You can
either put conditional code in your loop, or punt and write two versions of
the code: a fast one that works for 32 byte blocks, and one that doesn't use
dcbz for other block sizes. A third difficulty is accessing this instruction
from C code. You'll either need a compiler that supports inline assembly, or
you'll have to hand code the inner loop. The potential win of all this is
reducing your applications memory bandwidth by up to a third.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
"Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins)

+++++++++++++++++++++++++++

>From [e-mail] (Jon W‰tte)
Date: 14 Apr 1994 08:58:58 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (Phillip Burgess) writes:

>A couple of questions about programming on the Power Macintosh...

I would suggest a good book on processor architecture.

>working with 32-bit integer values?  If I'm writing a number of 32-bit
>values to a contiguous chunk of memory, do they (or can they) get stored
>in pairs about as quickly as storing half as many noncontiguous values?

Pretty much. It's more notable when you read sequentially through memory.

>If so, what sort of flaming hoops, if any, do I need to jump through?

None.

>If memory can be accessed in this fashion, what about writing 4 contiguous
>16-bit values, or 8 contiguous bytes?  Same effect?

Yeah, but misaligned reads take some time fixing up, and you also need
eight separate read/write instructions instead of two if you do bytes
instead of long words.

>Also, how many integer and FP registers am I likely to actually have at my
>disposal when using a C compiler such as MetroWorks'?

About 25 of each.

Cheers,

                    / h+
--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --

   There's no problem that can't be solved using brute-force algorithms
   and a sufficiently fast computer. Ergo, buy more hardware.    (NOT!)

---------------------------

>From [e-mail] (Humayun Lari)
Subject: QuickDraw GX Questions
Date: 28 Mar 1994 19:03:43 GMT
Organization: University of North Carolina, Chapel Hill

I have a couple of user-oriented questions about writing a graphics program
that uses GX. I don't have any obvious answers to these questions, so I'm
hoping someone else does:

1. Since QuickDraw GX uses quadratic curves, it seems like it's going to be
harder for users to edit GX paths than it is for users to edit Postscript
paths that use cubic curves -- a la FreeHand or Illustrator. I asked this
question a year ago, and Tom Dowdy replied to the effect that it didn't
matter, since the application could present a different model (e.g. cubic
curves) to the user. That's true, but how can cubic curves be converted
into quadratic curves without loss of accuracy? The GX libraries have a
routine that does the conversion, but its documentation indicates that the
result can be slightly off. Is this error acceptable?

2. The GX libraries use a 1-pixel wide bitmap ramp to produce linear
blends. Is there an effective way to produce radial blends that doesn't
require a huge bitmap and thus large storage requirements?

Appreciatively,

Humayun Lari
([e-mail])

+++++++++++++++++++++++++++

>From [e-mail] (Tom Dowdy)
Date: Fri, 1 Apr 1994 17:51:35 GMT
Organization: Apple Computer, Inc.

In article <2n79mf$[e-mail]>, [e-mail]
(Humayun Lari) wrote:
> 1. Since QuickDraw GX uses quadratic curves, it seems like it's going to be
> harder for users to edit GX paths than it is for users to edit Postscript
> paths that use cubic curves -- a la FreeHand or Illustrator. I asked this
> question a year ago, and Tom Dowdy replied to the effect that it didn't
> matter, since the application could present a different model (e.g. cubic
> curves) to the user. That's true, but how can cubic curves be converted
> into quadratic curves without loss of accuracy? The GX libraries have a
> routine that does the conversion, but its documentation indicates that the
> result can be slightly off. Is this error acceptable?

Well, since the result can be within 1 pixel (and you can't draw smaller
than that, and GX is device independant), the error is generally
acceptable.
The libraries show the basics of what need to be done -- and are
fairly accurate.  But they are provided as SOURCE CODE, so it's easy
to improve them from there.

However, if you need to make sure that when converting to something
that "supports" cubics native (like PostScript -- although actually
PostScript always blits everything as lines, and has it's own
error (curveerror) built in anyway) you attach to the shape a
cubic tag, which GX will use in preference to the quadratic data
when printing to a device that supports it (except if you apply
a non-linear transform to it (see below)).

As far as editing goes, you can present any model you wish to the
user -- and I honestly think that users don't want to EDIT using
control points (be they for quads or cubics) anyway.  There are
other editing models that are easier to use and that normal
people will probably prefer.

The question of quads vs. cubics has lots of history, but basically
(as far as GX is concerned) ends up stopping when you consider
the following:
 - cubics can't be intersected with other shape (the math is too difficult)
 - cubics can't be inset or outside mathematically, nor simplified
 - PostScript's implementation doesn't allow for perspective
transformation,
   so the cubic data can't be used in this case.

Developers of a GX savvy application will probably want to use many
of these features to let the user create shapes by combining/removing
and distorting exiting shapes to create new ones.  And because it
isn't mathematically possible to do this with cubics, these applications
will need to convert shapes into quadratics for these operations.

> 2. The GX libraries use a 1-pixel wide bitmap ramp to produce linear
> blends. Is there an effective way to produce radial blends that doesn't
> require a huge bitmap and thus large storage requirements?

Well, traditionally, blends aren't done with a bitmap, but with a
series of inset/outset shapes.  For Version 1.0 this the only way
to do radial blends.  This is how most applications do blends today.
Some do their blends in PostScript, when available, and you can still
do this with GX.  Simply attach a PostScript tag to the picture
shape containing your blend -- this tag will be used when possible,
and when it isn't possible, the picture shape data will be used.

Note that either of these methods is by it's nature device DEPENDANT.
This is no worse than today's world (with respect to these objects),
and maybe a bit better (due to more properly allowing alternate
representations).

A future version of GX will very likely provide a "multi-color" model
for shapes, which would also allow for this type of ramp.  But for
1.0 we had to stop someplace :-)

--
 Tom Dowdy                  Internet: [e-mail]
 Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
 1 Infinite Loop            AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

+++++++++++++++++++++++++++

>From [e-mail] (Humayun Lari)
Date: 3 Apr 1994 00:17:21 GMT
Organization: University of North Carolina, Chapel Hill

In article <dowdy-010494090912@17.202.72.12>, Tom Dowdy <[e-mail]>
wrote:
>As far as editing goes, you can present any model you wish to the
>user -- and I honestly think that users don't want to EDIT using
>control points (be they for quads or cubics) anyway.  There are
>other editing models that are easier to use and that normal
>people will probably prefer.

Tom, thank you for your detailed and thorough response. I'm very
appreciative, but a couple of your answers invite a couple more
questions...

I've worked with most of the major Macintosh drawing programs, and as far
as I know, none of them allow you to edit complex paths without using
cubic (or spline) control points. Sure, some of them allow you to draw
freehand and produce the path for you, but none provide a different
editing model that "normal people" would like. What kind of model are you
referring to?

>> 2. The GX libraries use a 1-pixel wide bitmap ramp to produce linear
>> blends. Is there an effective way to produce radial blends that doesn't
>> require a huge bitmap and thus large storage requirements?
>
>Well, traditionally, blends aren't done with a bitmap, but with a
>series of inset/outset shapes.  For Version 1.0 this the only way
>to do radial blends.  This is how most applications do blends today.
>Some do their blends in PostScript, when available, and you can still
>do this with GX.  Simply attach a PostScript tag to the picture
>shape containing your blend -- this tag will be used when possible,
>and when it isn't possible, the picture shape data will be used.
>
>Note that either of these methods is by it's nature device DEPENDANT.
>This is no worse than today's world (with respect to these objects),
>and maybe a bit better (due to more properly allowing alternate
>representations).
>
>A future version of GX will very likely provide a "multi-color" model
>for shapes, which would also allow for this type of ramp.  But for
>1.0 we had to stop someplace :-)

But by using a bitmap, the ramp library converts colors into RGB; doesn't
this make it device dependent? Or am I missing something? Similarly, if
radial blends are produced using, say, a sequence of 32 circles, would it
be appropriate to convert the blend colors into RGB before computing the
circle colors? Or would a color system such as CIE be more desirable?

Humayun Lari
([e-mail])

+++++++++++++++++++++++++++

>From [e-mail]
Date: 4 Apr 94 20:38:42 MST
Organization: (none)

In article <dowdy-010494090912@17.202.72.12>, [e-mail] (Tom Dowdy) writes:
> A future version of GX will very likely provide a "multi-color" model
> for shapes, which would also allow for this type of ramp.  But for
> 1.0 we had to stop someplace :-)
>
Speaking of stopping someplace, is there an AE Suite associated with the GX
API in the works?


Lawson

+++++++++++++++++++++++++++

>From [e-mail] (Tom Dowdy)
Date: Fri, 8 Apr 1994 18:03:15 GMT
Organization: Apple Computer, Inc.

In article <2nl1uh$[e-mail]>, [e-mail]
(Humayun Lari) wrote:

> I've worked with most of the major Macintosh drawing programs, and as far
> as I know, none of them allow you to edit complex paths without using
> cubic (or spline) control points. Sure, some of them allow you to draw
> freehand and produce the path for you, but none provide a different
> editing model that "normal people" would like. What kind of model are you
> referring to?

Well, one such model is constructing curves and shapes via the mathematical
joining and differencing of other shapes.  Another is by "nudging" or
"pulling" on areas of the curve using a shaped tool.

These can easily be done using QuickDraw GX geometry operations, and for
many types of editing may be more obvious for users.  Without GX geometry
doing the "hard work" for you, most applications writers have resorted
to using cubic or quadratic editing.  However, when cubic editing
first came out -- artists couldn't figure out how to use it.  This
shows that the *users* changed towards the model that the applications
provided rather than the other way around.

I *still* can't edit shapes via splines of any kind.

> >Note that either of these methods is by it's nature device DEPENDANT.
> >This is no worse than today's world (with respect to these objects),
> >and maybe a bit better (due to more properly allowing alternate
> >representations).
> >
> >A future version of GX will very likely provide a "multi-color" model
> >for shapes, which would also allow for this type of ramp.  But for
> >1.0 we had to stop someplace :-)
>
> But by using a bitmap, the ramp library converts colors into RGB; doesn't
> this make it device dependent? Or am I missing something? Similarly, if
> radial blends are produced using, say, a sequence of 32 circles, would it
> be appropriate to convert the blend colors into RGB before computing the
> circle colors? Or would a color system such as CIE be more desirable?

Yes, this is device DEPENDANT in terms of resolution-- this is no
worse than things are today.  This is what I said about.

However, it is still device indepedant with respect to color,
even when expressing colors via RGB space.

As far as what color space the colors should be expressed in -- this
is up to the application.  One of the wonderful things about GX
is that applications can express color in spaces that work best for
them and their users -- and GX takes care of converting to the
correct display or output space for you. Included in this is GX's
ability to correctly color match the results.

For ramps, most folks work in HSV/HSL or other "intensity" or "value"
type spaces.  CIE space is a bit difficult to produce ramps in --
probably even more so than RGB space.  But the important point
here is that it doesn't really matter.  Express the color as
YOU want (note that this includes bitmaps, which can be in
any GX's color spaces).

Even though everything except the CIE
family of spaces is technically a dependant color space, QuickDraw
GX allows all spaces to be calibrated through use of a gxColorProfile.
When you don't specifically provide a source color profile, QuickDraw
GX makes use of the default monitor profile provide via ColorSync.

--
 Tom Dowdy                  Internet: [e-mail]
 Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
 1 Infinite Loop            AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

+++++++++++++++++++++++++++

>From [e-mail] (Humayun Lari)
Date: 15 Apr 1994 13:41:01 -0400
Organization: The University of North Carolina at Chapel Hill

In article <dowdy-080494105252@17.202.72.12>,
Tom Dowdy <[e-mail]> wrote:
>Well, one such model is constructing curves and shapes via the mathematical
>joining and differencing of other shapes.  Another is by "nudging" or
>"pulling" on areas of the curve using a shaped tool.
>
>These can easily be done using QuickDraw GX geometry operations, and for
>many types of editing may be more obvious for users.  Without GX geometry
>doing the "hard work" for you, most applications writers have resorted
>to using cubic or quadratic editing.  However, when cubic editing
>first came out -- artists couldn't figure out how to use it.  This
>shows that the *users* changed towards the model that the applications
>provided rather than the other way around.
>
>I *still* can't edit shapes via splines of any kind.

Unfortunately, since existing applications *do* use splines, it seems
likely that programmers are going to continue using cubics or quadratics.
Users, as you say, have become accustomed to this model, so they may
actually *dislike* replacements. Beta 3 of GX doesn't appear to have any
examples of user interfaces that allow "nudging" or "pulling", which seem
to have the potential to replace the spline model. Does anyone (Tom? :-))
know of papers on such interfaces or have examples of existing applications
on other platforms that use better models? It would be ironic to have the
power of GX limited by old paradigms.

Humayun Lari
([e-mail])

---------------------------

>From [e-mail] (David Blume)
Subject: Quitting faceless background applications
Date: Wed, 13 Apr 1994 18:58:38 GMT
Organization: Gokuraku Videos - Wollongong Dept.

What is the prefered way for the user to quit a faceless background
application?  (Besides finding a way to generate a "Quit" Apple Event.)

Also, and more importantly, once the faceless background application
quits, how do we tell the finder to update the icon for the application?
(Even when faceless background applications quit, their icons in the finder
stay in the grayed out "in use" state.)

For an example, try quitting the "ledApp" application from the Dec Dev. CD.

Thanks!
--David
+---------------------------------------------------------------+
|  David Blume    |  "I get tired thinking of all the things I  |
|  [e-mail]  |   don't want to do."  --Bukowski, _Barfly_  |
+---------------------------------------------------------------+

+++++++++++++++++++++++++++

>From [e-mail] (Philippe Casgrain)
Date: Wed, 13 Apr 1994 21:58:48 +0100
Organization: Universite de Rennes-1, Fac. de medecine dentaire

In article <[e-mail]>, [e-mail] (David Blume)
wrote:

> What is the prefered way for the user to quit a faceless background
> application?  (Besides finding a way to generate a "Quit" Apple Event.)
>
    I like the way Greg Robbins did it in his "SmallDaemon" sample: if a
modifier key is detected at the same time an AppleEvent is received (he
used Caps Lock, but it could be anything), then quit the app.
    Thus, you could quit the FBA by double-clicking on it with the Caps Lock
key down.

> Also, and more importantly, once the faceless background application
> quits, how do we tell the finder to update the icon for the application?
> (Even when faceless background applications quit, their icons in the finder
> stay in the grayed out "in use" state.)
>
    I don't think you can, it's a bug in the Finder (or so I remember
reading... here ;-)

Philippe
--
[e-mail]
    Mac Hacker Lite

+++++++++++++++++++++++++++

>From [e-mail] (MarkHanrek)
Date: 14 Apr 1994 03:11:07 -0400
Organization: America Online, Inc. (1-800-827-6364)

>> What is the prefered way for the user to quit a faceless background
>> application?  Also, how do we tell the finder to update the icon for the
>> application?

The Finder icon for a faceless bkgnd task does not go back to normal after the
bkgnd task terminates. This is a bug and there is no workaround that I have
heard of.

Also, I would say that there is no preferred way for a user to terminate a
faceless bkgnd task, since these applications have no user interface, and if
there was a way, that would imply a user interface.

I would say that background-only applications should quit themselves and be
more like "agents". That would be more fun, eh? :)

In any case, I guess "it depends on the situation". (Dontcha hate answers like
that? :)

Mark Hanrek


+++++++++++++++++++++++++++

>From [e-mail] (Robert Cassidy)
Date: Thu, 14 Apr 1994 10:16:10 -0700
Organization: TLG Project

In article <2oiqab$[e-mail]>, [e-mail]
(MarkHanrek) wrote:

> >> What is the prefered way for the user to quit a faceless background
> >> application?  Also, how do we tell the finder to update the icon for the
> >> application?
>
> The Finder icon for a faceless bkgnd task does not go back to normal after the
> bkgnd task terminates. This is a bug and there is no workaround that I have
> heard of.
>
> Also, I would say that there is no preferred way for a user to terminate a
> faceless bkgnd task, since these applications have no user interface, and if
> there was a way, that would imply a user interface.
>
> I would say that background-only applications should quit themselves and be
> more like "agents". That would be more fun, eh? :)
>
> In any case, I guess "it depends on the situation". (Dontcha hate answers like
> that? :)
>
> Mark Hanrek

Powertalk Manager runs as an appe all the time. I haven't found of any good
way of killing it (other than running one of my buggier programs which
kills EVERYTHING :-)  FYI, Malph is a program which displays a list of all
running processes. It also includes appe's in the list and using balloon
help you can get such goodies as SIZE, Signature, location in memory, etc.
- very cool.

--
Robert Cassidy
TLG Project
UC Irvine

Let's hope 'Information SuperTollroad' isn't the catchphrase of the next
decade...

+++++++++++++++++++++++++++

>From David Casseres <[e-mail]>
Date: Thu, 14 Apr 1994 22:40:29 GMT
Organization: Apple Computer, Inc.

In article <2oiqab$[e-mail]> MarkHanrek, [e-mail]
writes:
> >> What is the prefered way for the user to quit a faceless background
> >> application?  Also, how do we tell the finder to update the icon for the
> >> application?
>
> The Finder icon for a faceless bkgnd task does not go back to normal after
the
> bkgnd task terminates. This is a bug and there is no workaround that I have
> heard of.
>
> Also, I would say that there is no preferred way for a user to terminate a
> faceless bkgnd task, since these applications have no user interface, and if
> there was a way, that would imply a user interface.
>
> I would say that background-only applications should quit themselves and be
> more like "agents". That would be more fun, eh? :)

Yeah, I think the whole original question is a bit confused.  If it's faceless
then *by definition* the user has no way to interact with it.  I'd say there
are really two categories of faceless background apps:

1.  System extensions, which are started by the system at startup and killed
at shutdown (though they may also be designed to quit themselves).  Their
icons never change in appearance, and the user doesn't normally look at them
since they're hidden away in the Extensions folder.

2.  Programs that are launched by other programs and then controlled by them.
The controlling program, assuming it has a user interface, might give the user
a way to kill the faceless background process.  When a program is launched by
some other program (not the Finder), its icon does not change in appearance.

I think maybe the original poster was thinking about a program with a
*minimal* user interface.  You can get away with no user interface except a
menu, which could contain a "Quit" item.  To do this the program should be a
normal Mac application, type 'APPL', launched normally by the Finder.  It
should be able to run both in foreground and background, since of course its
menu will only appear in the foreground.  The user can bring it to the
foreground by using the Finder's Application menu.

- -----------

David Casseres
Exclaimer: Hey!

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 15 Apr 1994 00:48:08 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail] (David Blume)
writes:

> What is the prefered way for the user to quit a faceless background
> application?  (Besides finding a way to generate a "Quit" Apple Event.)

Since faceless background applications don't have a user interface, you'll have
to send it a quit Apple event to tell it to shut down (or send it a signal some
other way).

> Also, and more importantly, once the faceless background application
> quits, how do we tell the finder to update the icon for the application?
> (Even when faceless background applications quit, their icons in the finder
> stay in the grayed out "in use" state.)

If the faceless background application is of file type 'APPL', then there's
nothing you can do about the grayed out icon.  The Finder doesn't track the
state of faceless background applications correctly (as pointed out by others).
 However, there's nothing forcing you to use type 'APPL'.

If you want the application automatically launched at system startup time, you
can use a file type of 'appe'.  If you use 'appe', then the Finder will
automatically put the application in the Extensions folder when the application
is dropped on the System Folder and the application will be launched a startup
time.

If you *don't* want the application launched at system startup time, you can
use just about any other file type that makes sense to you (don't use anything
goffy like 'TEXT'), but you'll have to launch the application yourself.

Here's an real-life example... The File Sharing Extension is an 'INIT' file in
the Extensions folder that implements Macintosh File Sharing.  The File Sharing
Extension contains an 'INIT' resource which installs the parts of the file
server software that always need to be available including the _ServerDispatch
(A094) trap.  One of the routines implemented through _ServerDispatch is
SCStartServer.  When SCStartServer is called, the trap code launches the file
server application.  Guess where the file server application code is?  It's in
the File Sharing Extension file (if you don't believe me, just look).

So, you could do something similar.  You'd just need to use a small application
to control your faceless background application.  The controlling application
would launch the faceless background application to start it and send the
faceless background application a quit Apple event when it needed to shut it
down.

- Jim Luther


---------------------------

End of C.S.M.P. Digest
**********************